Most modern applications maintain information about its user, such as what the user was doing the last time the user ran the application or what the user preferred for the configuration settings. This is extremely useful, since it allows a user to tailor the application to the user's own specific needs or working habits. The information maintained is commonly referred to as “state information”. Applications that do not maintain this state information are considered “stateless”.
The World Wide Web is intrinsically stateless because each request for a new Web page is processed without any knowledge of previous pages requested. This is because the HTTP protocol that defines the formats of the requests and corresponding responses does not currently define a mechanism for state information to be maintained. Because maintaining state information is extremely useful, programmers have developed a number of techniques to add state information to the World Wide Web. These include server application programming interfaces (APIs), such as NSAPI and ISAPI, and the use of cookies.
As described by Netscape, cookies are a general mechanism used by server side connections (such as CGI scripts) to both store and retrieve information on the client side of the connection. A server, when returning an HTTP object to a client, may also send a piece of state information which the client will store. Included in that state object is a description of the range of Uniform Resource Locators (URLs) for which that state is valid. Any future HTTP requests made by the client which fall in that range will include a transmittal of the current value of the state object from the client back to the server. The state object is called a cookie, for no compelling reason.
This mechanism provides a powerful tool which enables a host of new types of applications to be written for web-based environments. A common example of an application that uses cookies is a “virtual shopping mall”. As a user browses through a store of an on-line shopping mall and decides to purchase certain items, those items are added to the user's “shopping cart”. Specifically, a list of the chosen items is kept in the browser's cookie file (i.e., the “shopping cart”), so that all of the items can be paid for when shopping within that particular store is complete.
As stated above, cookies that have been saved by the browser will be transmitted on subsequent HTTP requests, if the URL associated with the request is in the range of URLs for which the cookie is valid. The range of URLs for which the cookie is valid depends on what has been specified, by the server side of the connection, for the “domain” and “path” attributes associated with the cookie. Netscape defines these attributes as follows:
domain=DOMAIN_NAME
                When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. “Tail matching” means that the domain attribute is matched against the tail of the fully qualified domain name of the host. A domain attribute of “acme.com” would match host names “anvil.acme.com”, as well as “shipping.crate.acme.com”.        Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: “.com”, “.edu”, and “va.us”. Any domain that falls within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: “COM”, “EDU”, “NET”, “ORG”, “GOV”, “MIL”, and “INT”.        The default value of a domain is the host name of the server which generated the cookie response.path=PATH        The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. The path “/foo” would match “/foobar” and “/foo/bar.html”. The path “/” is the most general path.        If the path is not specified, it is assumed to be the same path as the document being described by the header which contains the cookie.        
As an example, if a browser receives a response which contains a cookie with a domain attribute having a value of “.ibm.com” and a path attribute having a value of “/”, all subsequent requests made by the browser, to URLs that have a tail of “.ibm.com”, will contain the cookie. Furthermore, any subsequent requests made by that browser, to URLs that have a tail other than “.ibm.com”, will not contain the cookie.
Therefore, cookies are not shared across domains. This places limitations on the use of cookies. For instance, in the virtual shopping mall example described above, the user must check out any purchases at each individual store, since there is no way to keep track of the items from one store to another. As another example, since state information is not saved across domains, users must re-input login information for each domain. A single login is not possible.
Based on the foregoing, a need exists for a capability that enables the sharing of cookies across domains. Further, a need exists for a technique that allows a single check out in a virtual shopping mall, even when purchasing items from different vendors. Further, a need exists for a single login capacity. A yet further need exists for a capability that enables an intermediary application to provide state information to a client or a server.